Japanese Cloud Host Cn2 Practical Experience Sharing On Elastic Scaling And Bandwidth Peak Control

1. project background and goals

1) the project is a saas platform for japanese and east asian users, with the goal of ensuring 99.95% availability during peak access.
2) use japanese cn2 line cloud host to reduce latency and obtain stable bandwidth.
3) it is required to automatically expand the capacity when the traffic suddenly increases, and automatically shrink the capacity when the traffic drops to save costs.
4) cdn caching and origin site bandwidth control need to be combined to prevent origin site flooding and high bandwidth costs.
5) it also has basic ddos defense and ip layer rate limiting strategies to resist small-scale attacks and abnormal traffic.

2. initial server and network configuration example

1) initial host: 4 vcpu / 8 gb ram / 100 gb nvme, located in the tokyo computer room, directly connected to cn2.
2) basic bandwidth package: 100 mbps guaranteed, peak value increased to 1 gbps on demand (charged according to traffic).
3) system stack: ubuntu 22.04 + nginx 1.22 + php-fpm / node.js, using keepalived for primary and secondary switching.
4) monitoring: prometheus + grafana, used to collect bandwidth, number of connections, cpu, memory and disk i/o.
5) logs and alarms: the elk stack collects business logs, and prometheus alertmanager sets threshold alarms.

3. auto-scaling strategy and triggering conditions

1) horizontal expansion: when the 5-minute average bandwidth utilization exceeds 70% and the average cpu > 60%, a new instance is triggered.
2) scale-down strategy: scale down the instance when the 15-minute average bandwidth is less than 30% and the cpu < 20% and the number of active connections is low.
3) maximum/minimum number of instances: min=2, max=10 to ensure basic availability and cope with peaks.
4) cooling time: it will not be triggered repeatedly within 300s after expansion to avoid frequent expansion and contraction caused by jitter.
5) preheating mechanism: after elastic expansion, traffic reflow control (weight gradually increases) is used to avoid instant congestion.

4. practical operation of bandwidth peak control and cost optimization

1) set the connection rate limit (nginx limit_conn + limit_req) on the origin side, with a single ip concurrency limit of 50 and a qps limit of 200.
2) use cdn (covering japan/east asia) for static resource caching, with a static hit rate target of more than 85% to reduce the origin site bandwidth.
3) enable temporary peak bandwidth packages billed by the hour during peak hours (for example: increase to 500 mbps within 30 minutes).
4) use traffic shaping (tc + htb) for abnormal burst traffic, perform leaky bucket processing on the burst, and send it to the backend smoothly.
5) regularly purchase appropriate bandwidth packages based on traffic curves to avoid spikes in costs caused by long-term peak billing.

5. ddos defense and abnormal traffic handling

1) basic protection: operators/cloud vendors provide 10 gbps cleaning capabilities and enable traffic cleaning when the limit is exceeded.
2) application layer protection: waf rules block common injection, scanning and crawler behaviors.
3) ip blacklist and whitelist: add repeated attack sources to the blacklist and limit the rate, and add cooperative ips to the whitelist.
4) diversion strategy: switch suspected abnormal traffic into the grayscale pool (only static resources are allowed) to protect core business.
5) event response: the preset script automatically triggers the reduction of non-critical services and the expansion of cleaning nodes when traffic is abnormal.

6. real case: review of handling a traffic peak

1) event description: the traffic suddenly increased from 120 mbps to 820 mbps within 3 minutes after the start of a promotion.
2) trigger action: automatically expand 3 instances after monitoring alarms, refresh cdn cache and enable temporary 500 mbps bandwidth package.
3) effect: during the peak period, the source station bandwidth did not exceed 1.2 gbps, and the response time dropped from 600ms to 180ms.
4) consequences and optimization: it was found that some apis did not enable caching, and redis second-level cache was subsequently implemented to reduce back-end pressure.
5) cost: temporary bandwidth and capacity expansion added a total of approximately us$420 to the daily cost, but higher business losses were avoided.

7. configuration details and bandwidth data display

1) the following table shows common examples and bandwidth ratio examples for this project to facilitate quick selection and cost estimation.
2) the table shows the cpu, memory, basic bandwidth, temporary maximum bandwidth and applicable scenarios.
3) the table is displayed in the center, the border is 1, and the values ​​are typical values ​​that are truly observable in the experiment.
4) it is recommended to choose a bandwidth package or a flexible billing model based on the peak service frequency to balance cost and availability.
5) summary: combining cdn, speed limiting, elastic scaling and ddos cleaning, it can stably cope with most peak problems in japan's cn2 environment.

instance type	cpu	memory	basic bandwidth	temporary peak	applicable scenarios
small	2 vcpus	4gb	50mbps	200mbps	small traffic front-end/static site
standard	4 vcpus	8gb	100mbps	1 gbps	medium traffic api/application server
large	8 vcpus	16 gb	300mbps	5 gbps	highly concurrent business/data processing